X-MimeOLE: Produced By Microsoft Exchange V6.5
Received: by onstor-exch02.onstor.net 
	id <01C73D90.7B4A6DE1@onstor-exch02.onstor.net>; Sun, 21 Jan 2007 11:15:15 -0800
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C73D90.7B4A6DE1"
Content-class: urn:content-classes:message
Subject: RE:  RE: Functional Spec : Increase the number of TCP connections - for review
Date: Sun, 21 Jan 2007 11:15:15 -0800
Message-ID: <BB375AF679D4A34E9CA8DFA650E2B04E013D2A9F@onstor-exch02.onstor.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic:  RE: Functional Spec : Increase the number of TCP connections - for review
thread-index: Acc83H7MadyOqtJqQluj02kZHxGfjAAHozGwACUViZ8=
References: <BB375AF679D4A34E9CA8DFA650E2B04E0222879B@onstor-exch02.onstor.net>
From: "Paul Hammer" <paul.hammer@onstor.com>
To: "Jonathan Goldick" <jonathan.goldick@onstor.com>,
	"Shamsudeen Jeseem" <jeseem@onstor.com>,
	"dl-Design Review" <dl-designreview@onstor.com>,
	"Narayan Venkat" <narayan.venkat@onstor.com>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C73D90.7B4A6DE1
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Cheetah is supported but we have not defined the number of connections =
in the MRD for this chaissis type. Jonathan is correct that the ECR is =
from Toshiba and they are an all Cheetah enviorment (I believe).
=20
It was unclear to me why we need the cli commands for limitining the =
number of connections, when/why would a customer chosse use this =
command?
=20
Want us to be in sync on this; the number of connections is not the max, =
it is the tested/supported limit, there is no enforced maximum by =
chassis type, thus you should be able to attempt the same number of =
connections on a 2220 as a 2280. This is how I understood the requirment =
and what we discussed when we reviewed this requirement in the mRD =
review. If I am correct then there is no hard limit of tcp connections. =
Narayan please clarify this point, thanks..=20

________________________________

From: Jonathan Goldick
Sent: Sat 1/20/2007 5:25 PM
To: Shamsudeen Jeseem; dl-Design Review; Narayan Venkat
Subject: RE: Functional Spec : Increase the number of TCP connections - =
for review



1.      Update the copyright to 2007.  Jay made a new template somewhere =
with all this stuff handled.

2.      In section 1, there is a typo in the MRD link, you have an extra =
space in front of "Delorean MRD-PRD-REV1-7.xls"

3.      In section 4, is Cheetah really not required?  I only ask =
because the MRD mentions Nissho by name and their customers have =
Cheetah(s).  Narayan, please comment.

4.      In section 4, is CLUSDB_REC_TYPE_CORE_DUMP a typo?  I'm missing =
why we would put this under core dump but perhaps this relates to the =
comment in section 7 about avoiding a migration; it just seems confusing =
so I thought I'd ask.  Anyways, is it really required that we make this =
configurable?  Perhaps it's acceptable to just detect the model number =
and set the value?  If we could make this hard-wired per model number =
then we could cut out a number of the tasks and make this an easier =
project and test effort.  Narayan, please comment.

5.      Can we make section 7.1 its own major section since testing is =
not really a sub-chapter of Migration Strategy?

6.      In section 7.1, can we add a test where we send some load, even =
if it's low, across all the connections?  We need to know if the number =
of Ops we can service changes dramatically if the load is spread across =
a lot of connections versus our normal tests with very few connections.

7.      In section 7.1, we probably should add a statement that we are =
not able to make sure that this many connections will work properly with =
LinkAggregation set up.  While inn practice I would expect customers to =
use something to spread such a huge load around, we just don't have the =
infrastructure to simulate that number of clients in a way that =
exercises LinkAggregation.  This is probably more of a test about =
whether the switches actually function properly anyways.

8.      Once you get all of this working in a networking sense we need =
to determine whether it works in practice with so many CIFS or NFS =
connections.  If we could handle 1000 CIFS logons with Kerberos in 10 =
seconds(making this number up for discussion purposes) then 32K CIFS =
connections is about 5 minutes and makes sense, but is 128K really =
achievable and across how much time would we have to spread the initial =
connects to avoid overloading the auth-agent?  There is a similar issue =
for NFS mounts with non-trivial export options (NIS netgroups).  While =
what you are proposing looks pretty complete from a networking (NCPU) =
layer, I think we need more on the CIFS/NFS/Auth-Agent layer changes =
that might be required to make such a large number of connections =
actually usable.


------_=_NextPart_001_01C73D90.7B4A6DE1
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<HTML dir=3Dltr><HEAD><TITLE>RE: Functional Spec : Increase the number =
of TCP connections - for review</TITLE>=0A=
<META http-equiv=3DContent-Type content=3D"text/html; charset=3Dunicode">=0A=
<META content=3D"MSHTML 6.00.2900.3020" name=3DGENERATOR></HEAD>=0A=
<BODY>=0A=
<DIV id=3DidOWAReplyText78711 dir=3Dltr>=0A=
<DIV dir=3Dltr><FONT face=3DArial color=3D#000000 size=3D2>Cheetah is =
supported but we have not defined the number of connections in the MRD =
for this chaissis type. Jonathan is correct that the ECR is from Toshiba =
and they are an all Cheetah enviorment (I believe).</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2>It was unclear to me why we =
need the cli commands for limitining the number of connections, when/why =
would a customer&nbsp;chosse use this command?</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2>Want us to be in sync on =
this; the number of connections is not the max, it is the =
tested/supported limit, there is no enforced maximum by chassis type, =
thus you should be able to attempt the same number of connections on a =
2220 as a 2280. This is how I understood the requirment and what we =
discussed when we reviewed this requirement in the mRD review. If I am =
correct then there is no hard limit of tcp connections. Narayan please =
clarify this point, thanks.. </FONT></DIV></DIV>=0A=
<DIV dir=3Dltr><BR>=0A=
<HR tabIndex=3D-1>=0A=
<FONT face=3DTahoma size=3D2><B>From:</B> Jonathan =
Goldick<BR><B>Sent:</B> Sat 1/20/2007 5:25 PM<BR><B>To:</B> Shamsudeen =
Jeseem; dl-Design Review; Narayan Venkat<BR><B>Subject:</B> RE: =
Functional Spec : Increase the number of TCP connections - for =
review<BR></FONT><BR></DIV>=0A=
<DIV>=0A=
<P dir=3Dltr><FONT face=3D"Courier New" =
size=3D2>1.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT><SPAN lang=3Den-us> =
<FONT face=3D"Courier New" size=3D2>Update the copyright to 2007.&nbsp; =
Jay made a new template somewhere with all this stuff =
handled.</FONT></SPAN></P>=0A=
<P dir=3Dltr><SPAN lang=3Den-us><FONT face=3D"Courier New" =
size=3D2>2.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT></SPAN><SPAN =
lang=3Den-us> <FONT face=3D"Courier New" size=3D2>In section 1, there is =
a typo in the MRD link, you have an extra space in front of =
&#8220;</FONT><FONT face=3D"Courier New" size=3D2>Delorean =
MRD-PRD-REV1-7.xls</FONT><FONT face=3D"Courier New" =
size=3D2>&#8221;</FONT></SPAN></P>=0A=
<P dir=3Dltr><SPAN lang=3Den-us><FONT face=3D"Courier New" =
size=3D2>3.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT></SPAN><SPAN =
lang=3Den-us> <FONT face=3D"Courier New" size=3D2>In section 4, is =
Cheetah really not required?&nbsp; I only ask because the MRD mentions =
Nissho by name and their customers have =
Cheetah(s).&nbsp;</FONT></SPAN><SPAN lang=3Den-us> <FONT face=3D"Courier =
New" color=3D#ff0000 size=3D2>Narayan, please =
comment.</FONT></SPAN><SPAN lang=3Den-us></SPAN></P>=0A=
<P dir=3Dltr><SPAN lang=3Den-us><FONT face=3D"Courier New" =
size=3D2>4.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT></SPAN><SPAN =
lang=3Den-us> <FONT face=3D"Courier New" size=3D2>In section 4, =
is</FONT> <FONT face=3D"Courier New" =
size=3D2>CLUSDB_REC_TYPE_CORE_DUMP</FONT><FONT face=3D"Courier New" =
size=3D2> a typo?&nbsp; I'm missing why we would put this =
und</FONT><FONT face=3D"Courier New" size=3D2>er core dump but perhaps =
this relates to the comment in section 7 about avoiding a migration; it =
just seems confusing so I thought I</FONT><FONT face=3D"Courier New" =
size=3D2>&#8217;</FONT><FONT face=3D"Courier New" size=3D2>d ask.&nbsp; =
Anyways, is it really required that we make this configurable?&nbsp; =
Perhaps it</FONT><FONT face=3D"Courier New" size=3D2>&#8217;</FONT><FONT =
face=3D"Courier New" size=3D2>s acceptable to just detect the model =
n</FONT><FONT face=3D"Courier New" size=3D2>u</FONT><FONT =
face=3D"Courier New" size=3D2>mber and set the value?&nbsp; If we could =
make this hard-wired per model number then we could cut out a number of =
the tasks and make this an easier project and test =
effort.&nbsp;</FONT></SPAN><SPAN lang=3Den-us> <FONT face=3D"Courier =
New" color=3D#ff0000 size=3D2>Narayan, please =
comment.</FONT></SPAN><SPAN lang=3Den-us></SPAN></P>=0A=
<P dir=3Dltr><SPAN lang=3Den-us><FONT face=3D"Courier New" =
size=3D2>5.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT></SPAN><SPAN =
lang=3Den-us> <FONT face=3D"Courier New" size=3D2>Can we make section =
7.1 its own major section since testing</FONT><FONT face=3D"Courier New" =
size=3D2> is not really a sub-chapter of Migration =
Strategy?</FONT></SPAN></P>=0A=
<P dir=3Dltr><SPAN lang=3Den-us><FONT face=3D"Courier New" =
size=3D2>6.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT></SPAN><SPAN =
lang=3Den-us> <FONT face=3D"Courier New" size=3D2>In section 7.1, can we =
add a test where we send some load, even if it</FONT><FONT =
face=3D"Courier New" size=3D2>&#8217;</FONT><FONT face=3D"Courier New" =
size=3D2>s low, across all the connections?&nbsp; We need to know if the =
number of Ops we can service changes dramatically if the load is =
spread</FONT> <FONT face=3D"Courier New" size=3D2>across a lot of =
connections versus our normal tests with very few =
connections.</FONT></SPAN></P>=0A=
<P dir=3Dltr><SPAN lang=3Den-us><FONT face=3D"Courier New" =
size=3D2>7.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT></SPAN><SPAN =
lang=3Den-us> <FONT face=3D"Courier New" size=3D2>In section 7.1, we =
probably should add a statement that we are not able to make sure that =
this many connections will work properly with LinkAggregation set =
up.&nbsp; While inn pra</FONT><FONT face=3D"Courier New" size=3D2>ctice =
I would expect customers to use something to spread such a huge load =
around, we just don</FONT><FONT face=3D"Courier New" =
size=3D2>&#8217;</FONT><FONT face=3D"Courier New" size=3D2>t have the =
infrastructure to simulate that number of clients in a way that =
exercises LinkAggregation.&nbsp; This is probably more of a test about =
whether the switche</FONT><FONT face=3D"Courier New" =
size=3D2>s</FONT><FONT face=3D"Courier New" size=3D2> actually function =
properly anyways.</FONT></SPAN></P>=0A=
<P dir=3Dltr><SPAN lang=3Den-us><FONT face=3D"Courier New" =
size=3D2>8.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT></SPAN><SPAN =
lang=3Den-us> <FONT face=3D"Courier New" size=3D2>Once you get all of =
this working in a networking sense we need to determine whether it works =
in practice with so many CIFS or NFS connections.&nbsp; If we could =
handle 1000 CIFS logons with Kerberos in 10 seconds(making t</FONT><FONT =
face=3D"Courier New" size=3D2>his number up for discussion purposes) =
then 32K CIFS connections is about 5 minutes and makes sense, but is =
128K really achievable and across how much time would we have to spread =
the initial connects to avoid overloading the auth-agent?&nbsp; There is =
a simil</FONT><FONT face=3D"Courier New" size=3D2>a</FONT><FONT =
face=3D"Courier New" size=3D2>r issue for NFS mounts with non-trivial =
export options (</FONT><FONT face=3D"Courier New" size=3D2>NIS =
netgroups).&nbsp; While what you are proposing looks pretty complete =
from a networking (NCPU) layer, I think we need more on the =
CIFS/NFS/Auth-Agent layer changes that might be required to =
mak</FONT><FONT face=3D"Courier New" size=3D2>e such a large number of =
connections actually usable.</FONT></SPAN></P>=0A=
<P dir=3Dltr><SPAN lang=3Den-us></SPAN></P>=0A=
<P dir=3Dltr><SPAN lang=3Den-us></SPAN><SPAN lang=3Den-us></SPAN><SPAN =
lang=3Den-us></SPAN></P></DIV></BODY></HTML>
------_=_NextPart_001_01C73D90.7B4A6DE1--
